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(54) A method and apparatus for dynamic loading of a transport mechanism in a multipoint data 
delivery system 



(57) A method and apparatus for dynamic loading 
of a transport mechanism is provided. A resource loca- 
tor (RL) corresponding to a collaboration session is re- 
quested from a registry. A location indicator to the RL in 
the registry is received. In response to receiving the lo- 
cation indicator to the RL in the registry, a transportation 
mechanism specified in the first RL is dynamically load- 
ed, and the collaboration session is joined. Thus, users 
wishing to collaborate use the registry to determine the 
type of transport mechanism they need to dynamically 
load to communicate with each other. 
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Description 

FIELD OF THE INVENTION 

The present invention relates to multipoint data de- 
livery systems, and more specifically, to transport mech- 
anisms in a multipoint data delivery system. 

BACKGROUND OF THE INVENTION 

As computers become more important for business 
and entertainment, communication between computer 
users needs to be improved. One important function of 
computers is to distribute information to users and allow 
users to interact and collaborate. Prior art systems for 
distributing information and interaction include electron- 
ic mail (e-mail), mailing lists, making information avail- 
able through a bulletin board system or a world wide web 
page, and video conferencing. 

Electronic mail permits a user to send out informa- 
tion to a plurality of recipients. However, responses to 
e-mail are not easily collected. Additionally, multiple par- 
ties can not easily collaborate using e-mail. 

Mailing lists are useful for distributing information, 
but it is relatively difficult to tailor what information is re- 
ceived by a subscriber. Additionally, if replies are al- 
lowed, the mailing list may become overly cumbersome. 

A bulletin board system or world wide web page is 
useful to publish information. However, generally users 
can not easily alter the information displayed. Thus, this 
environment, while allowing publication, does not permit 
full collaboration between users. 

Video conferencing, and similar methods, may be 
used to collaborate on specific projects. However, video 
conferencing generally requires a dedicated computer 
system, which can not be used for something else dur- 
ing the video conference. Furthermore, generally video 
conference participation is typically limited due to the 
amount of processing power and network bandwidth re- 
quired to host each participant. Therefore, the number 
of participants in such conferences is significantly limit- 
ed. Thus, it is relatively difficult to have a long term col- 
laboration between multiple users via a video confer- 
encing system. 

When collaborations occur between multiple users 
using computers on different networks, different net- 
working protocols may be present. This generally re- 
quires multiple versions of software to be written, one 
version for each specific protocol. Therefore, it would be 
advantageous to have an improved mechanism for col- 
laboration which is also independent of the underlying 
network protocols. 

BRIEF SUMMARY OF THE INVENTION 

The present invention is a method and apparatus 
for dynamically loading a transport mechanism in a 
multipoint data delivery system. A multi-point data de- 
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livery system provides a communication mechanism be- 
tween users or a computer system which permits send- 
ing messages point to point, and point to multiple points. 
A resource locator (RL) corresponding to a collaboration 
5 session is requested from a registry. A location indicator 
of the RL in the registry is received from the registry. In 
response to receiving the location indicator of the RL in 
the registry, a transportation mechanism specified in the 
RL is dynamically loaded, and the collaboration session 
to is joined. The transportation mechanism is a protocol 
stack identifying the transportation protocol used. The 
transportation protocols may include transmission con- 
trol protocol (TCP), user datagrams protocol (UDP), re- 
mote method invocation (RMI), T.120, Common Object 
is Request Broker Architecture (CORBA), Scaleable Reli- 
able Multicast (SRM), and other transportation level im- 
plementations. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 

The present invention is illustrated by way of exam- 
ple, and not by way of limitation, in the figures of the 
accompanying drawings and in which like reference nu- 
merals refer to similar elements and in which: 
2S Figure 1 is a block diagram illustrating one embod- 
iment of a computer network in which the present inven- 
tion may be implemented. 

Figure 2 is an overview diagram of one embodiment 
of the present invention. 
30 Figure 3 is a block diagram illustrating an example 
of a session. 

Figure 4 is a block diagram illustrating one embod- 
iment of the overall application interface. 

Figure 5 is a flowchart illustrating one method of dy- 
35 namically loading the transport mechanism. 

DETAILED DESCRIPTION OF AN EMBODIMENT 

A method and apparatus for dynamic loading of a 

40 transport mechanism in a multipoint data delivery sys- 
tem is described. In the following description, for the pur- 
poses of explanation, numerous specific details are set 
forth in order to provide a thorough understanding of the 
present invention. It will be apparent, however, to one 

45 skilled in the art that the present invention may be prac- 
ticed without these specific details. In other instances, 
well-known structures and devices are shown in block 
diagram form in order to avoid unnecessarily obscuring 
the present invention. 

so Figure 1 is a block diagram illustrating one embod- 
iment of a computer network on which the present in- 
vention may be implemented. Computer systems 110 
are coupled to other computer systems 110 either di- 
rectly, using direct connection 120, or through a network 

55 1 30. In one embodiment, one or more of the computer 
systems 110 may be "clients" of a "session" conducted 
on another computer system 110. These terms are de- 
fined below. Alternately, one computer system 110 may 
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act as the server, while the other computer systems 110 
are clients. Alternately, the present invention may be im- 
plemented as a distributed system, having parts on 
more than one computer system. In an alternative em- 
bodiment, the present invention may be implemented 
on a single computer system 110. 

The present invention is related to dynamically 
loading a transportation protocol in a collaboration sys- 
tem in a computer network. According to one embodi- 
ment, a collaboration system is managed by computer 
system in response to a processor executing sequences 
of instructions contained in memory. Execution of the 
sequences of instructions causes the computer network 
to establish a collaboration session, add new sessions, 
and dynamically load transportation protocol in order to 
permit a user to join a collaboration session, as will be 
described hereafter. In 'alternative embodiments, circuit 
logic internal to a computer network may be used in 
place of or in combination with software to implement 
the present invention. Thus, the present invention is not 
limited to any specific combination of hardware and soft- 
ware. 

It is to be understood that although the term re- 
source locator (RL) is used in the specification, alternate 
methods of specifying an object on the Internet may be 
utilized without changing the spirit of the present inven- 
tion. Additionally, within an RL type, alternative access 
schemes or protocols may be utilized. Thus an RL cor- 
responding to file transfer protocol (ftp), telnet, etc. may 
be utilized. However, for simplicity's sake, the term RL 
will be utilized henceforth. 

Figure 2 is a block diagram illustrating one embod- 
iment of the collaboration system of the present inven- 
tion. The collaboration system 210 of the present inven- 
tion may be implemented on one or more computer sys- 
tems 110. The collaboration system 210 includes ele- 
ments which are implemented on a server computer and 
on a client computer. The server and client computers 
may however be the same computer. 

An application user interface 220 is an interface 
which displays information to the clients/users and re- 
ceives information from them. In one embodiment, the 
interface 220 may be a part of a world wide web browser 
application. The application user interface 220 is on the 
computer which acts as the client. 

The collaboration system 210 further includes a 
registry 230. The registry 230 contains information per- 
taining to the remote sessions and clients, permitting 
other computer systems to link to various sessions and 
become clients, as will be described below. In one em- 
bodiment, the registry 230 is a bootstrap name server. 
In one embodiment, the registry 230 is implemented on 
the computer which acts as the server. 

The collaboration system 210 further includes a 
parser 240. The parser 240 is for parsing a received re- 
source locator (RL). In one embodiment, the resource 
locator is a uniform resource locator (URL). The parser 
240 divides the RL into its component parts for further 



processing, as will be described below. The parser 240 
is implemented on the client computer. 

A dynamic loader 250 is a part of the collaboration 
system 210. The dynamic loader is for dynamically (i.e. 
s automatically) loading a protocol stack, stored in the 
memory 270. Tne dynamic loader 250 loads a protocol 
stack in response to an RL which designates a type of 
protocol to be used for a new session/client being es- 
tablished. The dynamic loader 250 receives the type 
designation from the registry 230, determines the ap- 
propriate protocol stack to be loaded for the type and 
retrieves the protocol stack from the memory 270. Thus, 
the dynamic loader 250 dynamically loads the appropri- 
ate protocol stack in response to receiving a type des- 
ignation. In one embodiment, the dynamic loader 250 is 
implemented on the client computer. 

A comparator 260 compares a received RL to RLs 
in the registry 230. The comparator 260 determines 
whether the received RL is already in the registry 230. 
The comparator 260 determines whether the RL needs 
to establish a new session, or join an already estab- 
lished session which is in the registry 220. The compa- 
rator 260 outputs a determination whether a matching 
RL was found in the memory 270 associated with the 
registry 230. The comparator 260 is implemented on the 
server computer. 

Session manager 280 manages each of the estab- 
lished sessions. Each established session has an RL in 
the registry 220 and at least one client. One example of 
a session is illustrated in Figure 3. A session manager 
280 is implemented on the computer which acts as the 
serverforthe particular session in question. For one em- 
bodiment, the server for a session need not be imple- 
mented on the same computer as the registry 230. 

Figure 3 illustrates an overview of a session 300 for 
collaborative computing. It permits multiple people to 
share an application. This session 300 may be for ex- 
ample, an on-line chat program, a shared white board, 
a gaming system, etc. 

Session 300 is a collection of related Clients 320, 
330, 360 which can exchange messages via defined 
communications paths 380, 395. Clients 320, 330, 360 
are actual or potential participants in an instance of mul- 
ti-party communications. Once properly associated with 
one another in a Session 300, related Clients 320, 330, 
360 can transfer data in a point-to-point or multipoint 
fashion. The Session 300 maintains the state associat- 
ed with the collection of clients 320, 330, 360 and their 
associated communications paths 380, 395, and may 
interact with an object which encapsulates a defined 
session management policy, manager 310. 

A Channel 380, 395 is a specific instance of a po- 
tentially multi-party communications path between two 
or more Clients 320, 330, 360 within a given Session 
300. A channel 380 may be shared between multiple 
clients 320, 330, 360, and two clients 320, 330 may es- 
tablish a separate channel 395. All Client objects 320, 
330, 360 which register an interest in receiving messag- 
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es from a given Channel 380, will get messages sent on 
that Channel 380. Any Client 320 which possesses an 
object reference to a Channel 380, 395 is able to send 
a message on the given Channel 380, 395, and a Client 
320 can have references to multiple Channels 380, 395. 
Thus, for example, Channel 380 for multi-party commu- 
nications can be separate from Channel 395 for com- 
munication between two Clients 320, 330. 

A Consumer 325, 335, 355, 365 is a Client object 
which has registered its interest in receiving messages 
sent over a given Channel 380, 395. Any Client 320, 
330, 360 can be a Consumer 325, 335, 355, 365 and it 
is possible for a given Client 330 to be a Consumer 335, 
355 of multiple Channels 380, 395 a the same time. A 
Client 320, 330, 360 sets a Consumer 325, 335, 355, 
365 on a Channel 380, 395 to receive Data sent over 
that Channel 380, 395. The Data contains the raw data, 
plus the senders name, the priority of the Data that was 
sent and the name of the Channel 380, 395 the Data 
was sent over. 

An Observer 31 5, 350, 390 is an object that has reg- 
istered its interest in being notified about changes in a 
state of another object. An Observer 315, 350, 390 can 
observe changes in a Session 300, on a Channel 380 
or a Token 340. A Session Observer 315 will be notified 
about Clients 320, 330, 360 joining and leaving a Ses- 
sion 300. A Channel Observer 390 will be notified about 
Clients 320, 330, 360 joining, leaving, being invited to 
join, and being expelled from a Channel 380, 395. A To- 
ken Observer 350 will be notified about Clients 320, 330, 
360 joining, leaving, being invited to join, or expelled 
from a Token 340. The Token Observer 350 is also no- 
tified when a Client 320, 330, 360 wishes to give or take 
a Token 340 from another Client 320, 330, 360. 

A Manager 31 0, 345, 385 encapsulates some man- 
agement policy for another given object. Access to a 
Session 300, Channel 380 or Token 340 can be control- 
led by assigning a Manager 310, 345, 385 to it at crea- 
tion time. The Manager 310, 345, 385 authenticates Cli- 
ents 320, 330, 360 wishing to join this resource, and 
based upon their response accepts or rejects them. 
Both send and receive access to individual Channels 
395 can be controlled by a private channel mechanism. 
Any Client 320, 330, 360 may convene a private Chan- 
nel 395 which results in the Client 320, 330, 360 becom- 
ing the private Channel Manager 385 of an empty chan- 
nel. The Channel Manager 385 can invite a Client 320, 
330, 360 to join the Channel 380 or force a Client 320, 
330, 360 to leave. 

A Token 340, 370 is a synchronization object which 
provides a unique distributed atomic operation. Tokens 
340, 370 can be used to implement a variety of different 
application-level synchronization mechanisms, for ex- 
ample to ensure mutually exclusive access to a shared 
resource. Tokens 340, 370 provide a means to imple- 
ment exclusive access. For example, to ensure in a 
multipoint application using resources that one and only 
one site holds a given resource at a given time, a Token 
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340, 370 can be associated with every resource. When 
a site wishes to use a specific resource, it must ask for 
its corresponding Token 340, 370, which will be granted 
only if no one else is holding it. A single Token 340, 370 
s may be used to coordinate a multiple client event by hav- 
ing each Client 320, 330, 360 take the Token 340, 370 
in a non-exclusive mode. Clients 320, 330, 360 can in- 
dependently inhibit and release the same Token 340, 
370. For example, if it was desired to know when all Cli- 
ff ents 320, 330, 360 have completed reception and 
processing of a bulk file transfer, all receiving Client 320, 
330, 360 would non-exclusively grab (inhibit) "the same 
Token 340, 370 and each individual Client 320, 330, 360 
would release the Token 340, 370 when it had complet- 
ed the proscribed process. Any Client 320, 330, 360 
could test the token 340, 370 at will to determine if the 
token 340, 370 is free which means all the Clients 320, 
330, 360 have completed processing. 



Within a multipoint Session 300 a Client 320, 330, 
360 can send data to different members of the Session 
300 and have access to tokens 340, 370 for resource 
contention resolution. This example will be explained 
with respect to Client D 330. However, it is to be under- 
stood that the explanation provided applies to any other 
client which joins a session. The first thing a Client 330 
has to do is join a Session 300. The Client 330 first de- 
termines what sessions are available to it. 

The Client 330 then joins a Session 300, or multiple 
sessions. The Session will typically have multiple Cli- 
ents 320, 330, 360, either at the same site or at different 
sites. An application or applet can have multiple Clients 
320, 330, 360 in the same Session 300. An applet is a 
platform independent program written in Sun Microsys- 
tem™^ Java™* language which can be distributed as 
an attachment in a World-Wide Web document and ex- 
ecuted by a web browser. Each Client 320, 330, 360 
might be handling a different kind of data, i.e. audio vs. 
video. A Client 330 can also be a member of multiple 
Sessions. 

Once the Session 300 is established, and the Client 
330 has joined the "Session 300, the Client 330 joins 
the appropriate Channels 380, 395 it requires for receiv- 
ing data. The use of these Channels 380, 395 is appli- 
cation dependent. Tokens 340, 370 are also provided 
for managing a resource available to the client. Chan- 
nels 380, 395 are session-wide addresses. Every Client 
320, 330, 360 of a Session 300 can join a Channel 380, 
395 to receive data sent to it, and by joining an appro- 
priate combination of Channels 380. 395, and by con- 
suming them, a Client 330 can choose to receive mes- 
sages sent to these Channels 380, 395 and ignore mes- 
sages sent to other Channels. The Client 330 subscribe 

* Sun, Sun Microsystems, the Sun logo, and Java are registered trade- 
marks of Sun Microsystems Inc. in the United States, and other coun- 
tries. 
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to and leave the desired Channels 380, 395 with the join 
and leave Channel methods. 

Once the participating Clients 320, 330, 360 have 
attached to the common Session 300 and joined the 
right combination of Channels 380, 395, they are ready 
to exchange data in a true multipoint fashion. 

Figure 4 is a block diagram illustrating the various 
levels of interactions within a collaboration environment. 
The lowest level is the transport level 41 0. The transport 
level 410 is utilized to interface with the network, and 
may include transmission control protocol (TCP), user 
datagrams protocol [UDP), remote method invocation 
(RMI), T.120, Common Object Request Broker Architec- 
ture (CORBA), Scaleable Reliable Multicast [SRM), and 
other transportation level 410 implementations. 

A registry 420 is one level above the transport level 
410. The registry 420 resides on the computer system 
which acts as the server and is used to keep track of all 
current sessions and clients. In one embodiment, the 
registry 420 is a bootstrap name server which allows a 
user to obtain remote sessions on a given host. The reg- 
istry 420 is, in effect, a record which contains a list of all 
available sessions and clients. Above the registry 420 
is the session management 430. The session manage- 
ment 430 acts as a manager of each individual session 
which is in progress. Each session has a separate man- 
agement block, and all of these management blocks to- 
gether form the session management 430. 

At the same level as the registry is the distributed 
data sharing 440. The distributed data sharing 440 per- 
mits the various types of data objects to be shared be- 
tween a n umber of clients. The data sharing 440 permits 
the sharing of the shared objects 450, shared primitives 
460, tokens 470, and publish/subscribe tuples 480. The 
distributed data sharing 440 also contains the Channels 
and data sending and receiving software. 

Shared objects 450 reside above the session man- 
agement 430. The shared objects 450 include sessions, 
channels, data, tokens, observers, consumers, manag- 
ers, and primitives. All of the data associated with these 
objects may be shared by using the data sharing 440. 
For one embodiment the Shared Objects 450 also allow 
objects to be shared outside the multipoint collaborative 
environment. 

Shared primitives 460 reside above the distributed 
data sharing 440 and session management 430. Shared 
primitives 460 are used to create and update simple 
named data elements which are shared between the 
members of a session. They may include boolean, dou- 
ble, float, integer, long, and string. Shared primitives 460 
always have an up-to-date internal value. 

Tokens 470 reside above the shared primitives 460. 
Tokens 470 provide a means to implement exclusive ac- 
cess to shared resources. Tokens 470 are associated 
with such a resource. When a site wishes to use a spe- 
cific resource, 'it must request its token, which will be 
granted only if no one else is holding the token. Tokens 
470 are also used to coordinate a multiple client event, 



by having non-exclusive tokens, which may be shared 
by multiple clients at the same time. 

Publish/subscribe tuples 480 reside above the 
shared primitives 460. Publish/subscribe tuples 480 are 
s associated with every client. The publish/subscribe tu- 
ples 480 permit a client to publish something on the col- 
laboration system, and to subscribe to publications of 
others. 

Figure 5 is a flowchart illustrating the flow of joining 
or registering a session with the registry 420. At block 
510 a universal resource locator (RL) is received from a 
client. In one embodiment, the resource locator, is in the 
following form: 

coll://<host>:<port>/<type>/Session/<session_ 
name> 
or 

coll://<host>:<port>/<type>/Client/<client_name> 
where the information in brackets "<>" is substituted by 
the actual name. Host: port designates the location of the 
designated server for this particular collaboration. The. 
host indicates the name of the host computer. The port 
indicates-the port number of the computer on which the 
present session or client is to be established. The type 
designates the type of connection used for the collabo- 
ration, including, for example, TCP, UDP, RMI, T.120, 
CORBA, SRM, and other transportation types. The Ses- 
sion or Client determines whether the RL is referencing 
a Session or a Client. The session name and client name 
are self-explanatory. 

At block 520, the RL is parsed. Parsing the RL sep- 
arates the elements described above, in order to ana- 
lyze the RL. 

At block 530, the received RL is compared to the 
RLs in the Registry. Each established session has an 
RL which is stored in the Registry, in order to permit oth- 
er users to connect to the same session. Thus, each 
element of the RL is compared to the RLs in the Registry. 

At block 540, the process determines whether such 
the received RL is identical to an RL in the Registry. If 
the RL is already in the registry, the process continues 
directly to block 570. Otherwise, the process continues 
to block 550. 

At block 550, the type of transportation mechanism 
specified in the RL is determined. That is, the type spec- 
ified, such as TCP, UDP, RMI, T.120, CORBA, SRM, is 
identified. Thus, for example, in an RL such as coll:// 
stard.Eng:4461/TCP/Session/ChatSession/ the type is 
TCP". 

At block 560, the new RL is added to the registry. 
Adding the RL to the registry allows later users/clients 
to register to join the collaborative session. The registry 
220 may have sessions with different transport mecha- 
nism. 

At block 570, a location indicator indicating the lo- 
cation of the established session is returned to the user. 
In one embodiment, the location indicator-is a pointer to 
the RL in the registry. In another embodiment, the loca- 
tion indicator is an Internet address. Inone embodiment. 
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the session is established on the same server that the 
registry is located on. Alternatively, the session may be 
established on a different computer, as indicated by the 
RL. 

At block 580, the client, in response to receiving the 
location Indicator, dynamically loads the object class, 
and the appropriate protocol stack. In one embodiment, 
the object class is a SharedData class. Each type of 
transport mechanism has a protocol stack, a layered set 
of protocols which work together to provide a set of net- 
work functions. The protocol stack may follow the Inter- 
national Standards Organization's seven layer model. 
Each client in the multipoint collaborative system has 
available at least one protocol stack. In response to re- 
ceiving the RL location indicator, the dynamic loader 250 
of the client loads the appropriate protocol stack, ena- 
bling the client to communicate with the session. In one 
embodiment, the protocol stack is loaded automatically, 
which means that a client or user need not interact with 
the present system in order to select a new protocol. 

In the foregoing specification, the invention has 
been described with reference to specific embodiments 
thereof. It will, however, be evident that various modifi- 
cations and changes may be made thereto without de- 
parting from the broader spirit and scope of the inven- 
tion. The specification and drawings are, accordingly, to 
be regarded in an illustrative rather than a restrictive 
sense. The present invention should not be construed 
as limited by such embodiments and examples, but rath- 
er construed according to the following claims and their 
equivalents. 

The processes described above may be performed 
by a computer program running on a computer in the 
embodiment described. Such a computer program can 
be recorded on a recording medium (for example a mag- 
netic disc or tape, an optical disc or an electronic mem- 
ory device, such as a ROM) in a way well known to those 
skilled in the art. When the recording medium is read by 
a suitable reading device, such as a magnetic or optical 
disc drive, a signal is produced which causes a compu- 
ter to perform the processes described. 

The processes may also be performed by electronic 
means. 

Claims 

1. A method of joining a collaboration session com- 
prising the steps of: 

requesting a resource locator (RL) to the col- 
laboration session from a registry; 
receiving a location indicator to a stored RL in 
the registry; and 

in response to receiving the location indicator 
to the RL In the registry, dynamically loading a 
transportation mechanism specified in the RL; 
and 
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joining the collaboration session. 

2. The method of claim 1 wherein the step of dynam- 
ically loading the transportation mechanism further 

s includes the steps of: 

creating a new instance of an object class cor- 
responding to a type of the transportation 
mechanism; 

10 retrieving a protocol stack corresponding to the 

transportation mechanism; and 
initiating the protocol stack. 

3. The method of claim 1 including the steps of: 

15 

receiving a first resource locator (RL); 
determining if the first RL is matched to a plu- 
rality of RLs in the registry; 
if the first RL is not matched to the plurality of 
20 RLs in the registry, adding the first RL to the 

plurality of RLs in the registry; and 
returning the location indicator to a correspond- 
ing stored RL of the plurality of RLs in the reg- 
istry. 

25 

4. The method of claim 1, wherein the RL further in- 
cludes a host and a port identification, a session or 
client identification, and a session or client name. 

30 5. An apparatus for facilitating collaboration among 
computer users comprising: 

a client process for requesting a session for the 
collaboration; 

3S the client process for receiving a location indi- 

cator to an RL, the RL including a type desig- 
nation; and 

a dynamic loader for loading a transportation 
mechanism corresponding to the type designa- 
te tion of the RL. 

6. The apparatus of claim 5 wherein the type designa- 
tion of the RL identifies a type of a transportation 
mechanism used for the collaboration. 

45 

7. The apparatus of claim 6 wherein the transportation 
mechanism may be one of the following: transmis- 
sion control protocol (TCP), user datagrams proto- 
col (UDP), remote method invocation (RMI), T.120, 

so Common Object Request Broker Architecture 
(CORBA), Scaleable Reliable Multicast (SRM). 

8. The apparatus of claim 6, wherein the RL further 
includes a host and a port identification, a session 

55 or client identification, and a session or client name. 

9. The apparatus of claim 6, wherein the client process 
receives the RL from a server process. 
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10. A computer data signal embodied in a carrier wave 
and representing sequences of instructions which, 
when executed by a processor, cause said proces- 
sor to join a collaboration session, said computer 
data signal comprising: 

a first computer program being executable to 
request a resource locator (RL) corresponding 
to the collaboration session from a registry; 
a first operating system procedure being exe- 
cutable to receive a location indicator to the RL 
in the registry; and 

a second computer program being executable 
to dynamically load a transportation mecha- 
nism specified in the first RL join the collabora- 
tion session. 

11. The computer data signal of claim 10 wherein the 
second computer program further includes: 

a first subprogram being executable to create 
a new instance of an object class correspond- 
ing to a type of the transportation mechanism; 
and 

a second subprogram being executable to re- 
trieve a protocol stack corresponding to the 
transportation mechanism; and 
a third subprogram being executable to initiate 
the protocol stack. 

1 2. A machine readable medium having stored thereon 
data representing sequences of instructions, which 
when executed by a computer system, cause said 
computer system to join a collaboration, said se- 
quences of instructions comprising: 

a first sequence for requesting a resource loca- 
tor (RL) corresponding to a collaboration ses- 
sion from a registry; 

a second sequence for receiving a location in- 
dicator to the RL in the registry; and 
a third sequence for dynamically loading a 
transportation mechanism specified in the first 
RL in response to receiving the location indica- 
tor to the RL in the registry; and 
a fourth sequence for joining the collaboration 
session. 

13. The machine readable medium of claim 12, wherein 
the third sequence further includes: 

a fifth sequence for creating a new instance of 
an object class corresponding to a type of the 
transportation mechanism; 
a sixth sequence for retrieving a protocol stack 
corresponding to the transportation mecha- 
nism; and 

a seventh sequence for initiating the protocol 



stack. 

14. A signal according to claim 10 or 11, wherein the 
signal is recorded on a recording medium. 

s 

15. A signal according to claim 14, wherein the record- 
ing medium comprises a magnetic disc, a magnetic 
tape, an optical disc or an electronic memory de- 
vice. 
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